[#828] Fix infinite loop picking the errors-encountered LDIF file name - #839
Merged
vharseko merged 1 commit intoAug 4, 2026
Conversation
…ntered LDIF file name The loop in LDIFConnectionHandler.processLDIFFile() which picks a free .errors-encountered.<timestamp> name never terminated: it had no break and kept appending numeric suffixes, hanging the handler thread and growing the path string until OutOfMemoryError. Replace both name-picking blocks (.applied and .errors-encountered) with a single testable helper which stops at the first free name. The rename and delete of the source file now use StaticUtils.renameFile() and Files.delete(), so a failure is logged and raises an alert instead of being silently ignored.
vharseko
added
bug
java
maximthomas
approved these changes
Aug 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #828.
LDIFConnectionHandler.processLDIFFile()never left the loop which picks a free.errors-encountered.<timestamp>name: it had nobreak, and every iteration whose candidate was free appended another numeric suffix, so the handler thread hung and the path string grew untilOutOfMemoryError. The twin block for the.appliedname a few lines above has the intendedbreak, which confirms the loop shape that was meant here.Changes:
.appliedand.errors-encountered) are replaced with a single package-private helperselectUnusedPath(), which stops at the first free name.StaticUtils.renameFile(), and the delete of an applied source file throughFiles.delete(), so a failure throws and the existingcatchblocks finally logERR_LDIF_CONNHANDLER_CANNOT_RENAME/ERR_LDIF_CONNHANDLER_CANNOT_DELETEand raise the alert instead of silently ignoring the returnedfalse. TherenameFileline is textually identical to the one in Fix CodeQL note-severity alerts: ignored error status of file and stream calls #814, so the two PRs merge cleanly in either order.Tests:
testSelectUnusedPath— unit test of the helper: a free base name is used as-is, a taken one gets.2, and with.2/.3taken the helper picks.4with exactly one suffix appended (the old loop kept stacking suffixes).testUnparseableLDIFErrorsNameTaken— end-to-end reproduction of LDIF connection handler hangs in an infinite loop when the .errors-encountered file name is taken #828: every.errors-encountered.<timestamp>name the handler may pick is pre-created, and the unparseable file must still be renamed to the.2variant. With the old code this test hangs the handler thread.LDIFConnectionHandlerTestCase: 6/6 passed (mvn -pl opendj-server-legacy -P precommit verify -Dit.test=LDIFConnectionHandlerTestCase).